Russ Allbery: Review: Grimspace
Series: | Sirantha Jax #1 |
Publisher: | Ace |
Copyright: | March 2008 |
ISBN: | 0-441-01599-9 |
Format: | Mass market |
Pages: | 312 |
Series: | Sirantha Jax #1 |
Publisher: | Ace |
Copyright: | March 2008 |
ISBN: | 0-441-01599-9 |
Format: | Mass market |
Pages: | 312 |
mspdebug
and gcc-msp430
provide all I need to compile (make config && make
) and upload (mspdebug rf2500 "prog ../foo.txt"
) new software.shelob ~/git/blogspam.js $ node blogspam.js Loaded plugin: ./plugins/10-example.js Loaded plugin: ./plugins/20-ip.js Loaded plugin: ./plugins/80-sfs.js Loaded plugin: ./plugins/99-last.js Received submission: "body":"This is my body ..","ip":"109.194.111.184","name":"Steve Kemp" plugin 10-example.js said next :next plugin 20-ip.js said next :next plugin 99-last.js said spam SPAM: Listed in StopForumSpam.comSo we've loaded plugins, and each has been called. But the end result was "SPAM: Listed .." and yet the caller didn't get that result. Instead the caller go this:
shelob ~/git/blogspam.js $ ./client.pl 200 OK 99-last.jsThe specific issue is that I iterate over every loaded-plugin, and wait for them to complete. Because they complete asynchronously the plugin which should be last, and just return "OK" , has executed befure the 80-sfs.js plugin. (Which makes an outgoing HTTP request). I've looked at async, I've looked at promises, but right now I can't get anything working. Meh. Surprise me with a pull request ;)
Signal
helper class, which makes defining custom signals a whole lot simpler and more obvious. In the past, you had to do
class C(GObject.GObject): __gsignals__ = 'my_signal': (GObject.SIGNAL_RUN_FIRST, GObject.TYPE_NONE, (GObject.TYPE_INT,)) def do_my_signal(self, arg): print("my_signal called with %i" % arg)whereas now this looks like
class C(GObject.GObject): @GObject.Signal(arg_types=(int,)) def my_signal(self, arg): print("my_signal called with %i" % arg)or even more elegantly when using Python 3 and its new type annotations:
class C(GObject.GObject): @GObject.Signal def my_signal(self, arg:int): print("my_signal called with %i" % arg)Check out the updated example and docstring for other ways how to use it. Overrides can now be in a directory different from the one that pygobject installs itself into. These overrides need to put this into their
__init__.py
at the top:
from pkgutil import extend_path __path__ = extend_path(__path__, __name__)and put themselves somewhere into the default
PYTHONPATH
. This should make it a lot easier for library packages to ship their own overrides for Python.
This new version also comes with a couple of new overrides and bug fixes. See the detailled list of changes below.
Thanks to all contributors!
GParamSpec
attributes and return values, as well as a few small bug fixes.
Thanks to all contributors!
Complete list of changes:
master:/srv/leader/news/bits-from-the-DPL.*
Detailed floor plans automatically appear when you re viewing the map and zoomed in on a building where indoor map data is available. The familiar blue dot icon indicates your location within several meters, and when you move up or down a level in a building with multiple floors, the interface will automatically update to display which floor you re on. All this is achieved by using an approach similar to that of My Location for outdoor spaces, but fine tuned for indoors.Thoughts about this:
Once upon a time, there was Deb and Ian. That was about exactly 18 years ago. We don t talk about the 0.939000 format any more, but they eventually settled on:
$ ar rc pkg_1.0_all.deb debian-binary control.tar.gz data.tar.gz $ hexdump -C pkg_1.0_all.deb head 00000000 21 3c 61 72 63 68 3e 0a 64 65 62 69 61 6e 2d 62 !<arch>.debian-b 00000010 69 6e 61 72 79 20 20 20 31 33 31 33 36 38 33 35 inary 13136835 00000020 32 39 20 20 31 30 30 36 20 20 32 30 30 20 20 20 29 1006 200 00000030 31 30 30 36 34 34 20 20 34 20 20 20 20 20 20 20 100644 4 00000040 20 20 60 0a 32 2e 30 0a 63 6f 6e 74 72 6f 6c 2e .2.0.control. 00000050 74 61 72 2e 67 7a 20 20 31 33 31 33 36 38 33 35 tar.gz 13136835 00000060 32 39 20 20 31 30 30 36 20 20 32 30 30 20 20 20 29 1006 200 00000070 31 30 30 36 34 34 20 20 31 33 39 31 20 20 20 20 100644 1391 00000080 20 20 60 0a 1f 8b 08 00 00 00 00 00 00 03 ed 59 ............Y 00000090 eb 6f db 36 10 f7 d7 f0 af b8 3a 5e 9b 74 b1 f5 .o.6......:^.t..
By then, systems were a.out(5), and everything was good. (Of course, if you look at the mtimes, you ll notice I faked this. But it s really equivalent to the real thing.
But oh horror! GNU binutils, not always everyone s friend, switched from using BSD style Unix Archiver libraries in ar(1) to SYSV style libraries on elf(5) systems:
$ ar rc on-elf debian-binary control.tar.gz data.tar.gz $ hexdump -C on-elf head 00000000 21 3c 61 72 63 68 3e 0a 64 65 62 69 61 6e 2d 62 !<arch>.debian-b 00000010 69 6e 61 72 79 2f 20 20 31 33 31 33 36 38 33 35 inary/ 13136835 00000020 32 39 20 20 31 30 30 36 20 20 32 30 30 20 20 20 29 1006 200 00000030 31 30 30 36 34 34 20 20 34 20 20 20 20 20 20 20 100644 4 00000040 20 20 60 0a 32 2e 30 0a 63 6f 6e 74 72 6f 6c 2e .2.0.control. 00000050 74 61 72 2e 67 7a 2f 20 31 33 31 33 36 38 33 35 tar.gz/ 13136835 00000060 32 39 20 20 31 30 30 36 20 20 32 30 30 20 20 20 29 1006 200 00000070 31 30 30 36 34 34 20 20 31 33 39 31 20 20 20 20 100644 1391 00000080 20 20 60 0a 1f 8b 08 00 00 00 00 00 00 03 ed 59 ............Y 00000090 eb 6f db 36 10 f7 d7 f0 af b8 3a 5e 9b 74 b1 f5 .o.6......:^.t..
Can you spot the difference?
Of course, ELF is what you want , so there is little choice. Unix Archiver libraries are system dependent, and no format has ever been normed, but DEB files use it as format so what is one to do?
$ GNUTARGET=a.out-i386-linux ar rc with-aout \ > debian-binary control.tar.gz data.tar.gz $ md5sum pkg_1.0_all.deb with-aout on-elf 248f78d42f8ca8f2a3560f9800b2bf01 pkg_1.0_all.deb 248f78d42f8ca8f2a3560f9800b2bf01 with-aout 09eca70c9b11b6b55bbadcab5c3201fb on-elf
OK, and what do I do on my Debian/m68k system?
ar(1) uses bfd, and GNU binutils can not only forcibly set the target emulation but also show them:
ar: supported targets: elf32-m68k a.out-m68k-linux elf32-little elf32-big plugin srec symbolsrec verilog tekhex binary ihex trad-core
debian_i386$ ar -h 2>&1 grep '^ar: supported targets'
ar: supported targets: elf32-i386 a.out-i386-linux pei-i386 elf32-little elf32-big elf64-x86-64 elf32-x86-64 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big plugin srec symbolsrec verilog tekhex binary ihex trad-core
debian_i386$ ar -h 2>&1 grep '^ar: supported targets' # binutils-multiarch
ar: supported targets: elf32-i386 a.out-i386-linux pei-i386 elf32-little elf32-big elf64-alpha ecoff-littlealpha elf64-little elf64-big elf32-littlearm elf32-bigarm elf32-hppa-linux elf32-hppa elf64-x86-64 elf32-x86-64 elf64-l1om elf64-k1om elf64-ia64-little elf64-ia64-big pei-ia64 elf32-m68k a.out-m68k-linux coff-m68k versados ieee a.out-zero-big elf32-tradbigmips elf32-tradlittlemips ecoff-bigmips ecoff-littlemips elf32-ntradbigmips elf64-tradbigmips elf32-ntradlittlemips elf64-tradlittlemips elf32-powerpc aixcoff-rs6000 elf32-powerpcle ppcboot elf64-powerpc elf64-powerpcle aixcoff64-rs6000 aix5coff64-rs6000 elf32-s390 elf64-s390 elf32-shbig-linux elf32-sh-linux elf32-sh64-linux elf32-sh64big-linux elf64-sh64-linux elf64-sh64big-linux elf32-sparc a.out-sparc-linux elf64-sparc a.out-sunos-big pei-x86-64 elf32-m32r-linux elf32-m32rle-linux elf32-spu plugin srec symbolsrec verilog tekhex binary ihex trad-core
mirbsd_i386$ ar -h 2>&1 grep '^ar: supported targets'
ar: supported targets: elf32-i386 coff-a29k-big a.out.adobe aix5coff64-rs6000 a.out-zero-big a.out-mips-little epoc-pe-arm-big epoc-pe-arm-little epoc-pei-arm-big epoc-pei-arm-little coff-arm-big coff-arm-little a.out-arm-netbsd pe-arm-big pe-arm-little pei-arm-big pei-arm-little b.out.big b.out.little efi-app-ia32 efi-app-ia64 elf32-avr elf32-big elf32-bigarc elf32-bigarm elf32-bigarm-symbian elf32-bigarm-vxworks elf32-bigmips elf32-cr16c elf32-cris elf32-crx elf32-d10v elf32-d30v elf32-dlx elf32-fr30 elf32-frv elf32-frvfdpic elf32-h8300 elf32-hppa-linux elf32-hppa-netbsd elf32-hppa elf32-i370 elf32-i386-freebsd elf32-i386-vxworks elf32-i860-little elf32-i860 elf32-i960 elf32-ia64-hpux-big elf32-ip2k elf32-iq2000 elf32-little elf32-littlearc elf32-littlearm elf32-littlearm-symbian elf32-littlearm-vxworks elf32-littlemips elf32-m32r elf32-m32rle elf32-m32r-linux elf32-m32rle-linux elf32-m68hc11 elf32-m68hc12 elf32-m68k elf32-m88k elf32-mcore-big elf32-mcore-little elf32-mn10200 elf32-mn10300 elf32-msp430 elf32-nbigmips elf32-nlittlemips elf32-ntradbigmips elf32-ntradlittlemips elf32-openrisc elf32-or32 elf32-pj elf32-pjl elf32-powerpc elf32-powerpc-vxworks elf32-powerpcle elf32-s390 elf32-sh elf32-shbig-linux elf32-shl elf32-shl-symbian elf32-sh-linux elf32-shl-nbsd elf32-sh-nbsd elf32-sh64 elf32-sh64l elf32-sh64l-nbsd elf32-sh64-nbsd elf32-sh64-linux elf32-sh64big-linux elf32-sparc elf32-tradbigmips elf32-tradlittlemips elf32-us-cris elf32-v850 elf32-vax elf32-xstormy16 elf32-xtensa-be elf32-xtensa-le elf64-alpha-freebsd elf64-alpha elf64-big elf64-bigmips elf64-hppa-linux elf64-hppa elf64-ia64-big elf64-ia64-hpux-big elf64-ia64-little elf64-little elf64-littlemips elf64-mmix elf64-powerpc elf64-powerpcle elf64-s390 elf64-sh64 elf64-sh64l elf64-sh64l-nbsd elf64-sh64-nbsd elf64-sh64-linux elf64-sh64big-linux elf64-sparc elf64-tradbigmips elf64-tradlittlemips elf64-x86-64 mmo pe-powerpc pei-powerpc pe-powerpcle pei-powerpcle a.out-cris demo64 ecoff-bigmips ecoff-biglittlemips ecoff-littlemips ecoff-littlealpha coff-go32 coff-go32-exe coff-h8300 coff-h8500 a.out-hp300hpux a.out-i386 a.out-i386-bsd coff-i386 a.out-i386-freebsd a.out-i386-lynx coff-i386-lynx msdos a.out-i386-netbsd i386os9k pe-i386 pei-i386 coff-i860 coff-Intel-big coff-Intel-little ieee coff-m68k coff-m68k-un a.out-m68k-lynx coff-m68k-lynx a.out-m68k-netbsd coff-m68k-sysv coff-m88kbcs a.out-m88k-mach3 a.out-m88k-openbsd mach-o-be mach-o-le mach-o-fat coff-maxq pe-mcore-big pe-mcore-little pei-mcore-big pei-mcore-little pe-mips pei-mips a.out-newsos3 nlm32-alpha nlm32-i386 nlm32-powerpc nlm32-sparc coff-or32-big a.out-pc532-mach a.out-ns32k-netbsd a.out-pdp11 pef pef-xlib ppcboot aixcoff64-rs6000 aixcoff-rs6000 coff-sh-small coff-sh coff-shl-small coff-shl pe-shl pei-shl coff-sparc a.out-sparc-little a.out-sparc-linux a.out-sparc-lynx coff-sparc-lynx a.out-sparc-netbsd a.out-sunos-big sym a.out-tic30 coff-tic30 coff0-beh-c54x coff0-c54x coff1-beh-c54x coff1-c54x coff2-beh-c54x coff2-c54x coff-tic80 a.out-vax-bsd a.out-vax-netbsd a.out-vax1k-netbsd versados vms-alpha vms-vax coff-w65 coff-we32k coff-z8k elf32-am33lin elf32-ms1 srec symbolsrec tekhex binary ihex netbsd-core
debian_m68k$ ar -h 2>&1 grep '^ar: supported targets'Wow. While binutils share no single supported working target, they can be built multiarch, or (on MirBSD) with --enable-targets=all --enable-64-bit-bfd. Doesn t help if you want to stay portable: GNUTARGET=srec is common on all Debian (sid) binutils versions (single or multiarch), but errors out on older binutils. The a.out-* targets are not common. Sure, you could hack around things, but this is tedious. If you follow things or know me a little, you might already have guessed that I wouldn t let that stand.
pax(1) to the rescue. On MirBSD, we use paxtar, which has cpio(1) and tar(1) front-ends and supports multiple formats (4 cpio and 2 tar variants) and has already been extended a lot and is lovingly called paxmirabilis (mirabilos peace in Latin) it has options to anonymise archives: set uid and gid to zero, set mtime to zero, (for ustar) only write the numeric uid and gid to the archive, (for cpio formats) serialise inodes and device information, write content of hardlinked files only once (breaks partial extraction but saves a lot of space, e.g. 2 MiB off the Grml initrd.gz). And, recently, the ability to append a trailing slash to pathnames of ustar members which are directories (GNU tar does it and I thought some Debian utilities check for it). So why not (the -M dist and fakeroot set the uid/gid to 0)
$ find debian-binary control.tar.gz data.tar.gz \ > mircpio -oHar -Mdist >with-mircpio $ mirpax -w -M dist -f with-mirpax -x ar \ > debian-binary control.tar.gz data.tar.gz $ mirtar -M dist -A -cf with-mirtar \ > debian-binary control.tar.gz data.tar.gz $ GNUTARGET=a.out-i386-linux fakeroot ar rc with-aout-ar \ > debian-binary control.tar.gz data.tar.gz $ md5sum with-* a466e2fd57cdee141fe585a43245548f with-aout-ar a466e2fd57cdee141fe585a43245548f with-mircpio a466e2fd57cdee141fe585a43245548f with-mirpax a466e2fd57cdee141fe585a43245548f with-mirtar
Voil . I got it, and even appending is possible. It supports the BSD format with special focus on DEB files, and deals with long filenames, but not symbol or filename tables (used by ranlib(1) or strange formats, respectively, but since we don t create *.a files to use with some native linker/binder/loader, we don t need that anyway).
On extraction (oh, and listing!) it deals with SYSV style filenames as well.
$ mirtar tvf on-elf -rw-r--r-- 1 tg tg 4 Aug 18 16:05 debian-binary -rw-r--r-- 1 tg tg 1391 Aug 18 16:05 control.tar.gz -rw-r--r-- 1 tg tg 18135 Aug 18 16:05 data.tar.gz $ mirtar tvf with-aout -rw-r--r-- 1 tg tg 4 Aug 18 16:05 debian-binary -rw-r--r-- 1 tg tg 1391 Aug 18 16:05 control.tar.gz -rw-r--r-- 1 tg tg 18135 Aug 18 16:05 data.tar.gz
One of the real benefits is that you can use the front-ends interchangably for example, mirtar tzf foo.cpio.gz would work (which GNU tar can t do), and mircpio s ustar implementation, unlike GNU cpio s, is not horribly broken. Of course, there are some drawbacks: it s not GNU tar or GNU cpio, so there are absolutely zero --long-options. Some of their features are missing (but tar s -O is implemented now), so it s no replacement (but very well usable alongside it). The format called pax, committee-designed to replace ustar, isn t yet supported ironically, but that s on the TODO.
So, what do you think?
tg@frozenfish:~/Debs/dists/sid/wtf/Pkgs/mircpio $ ll *.deb -rw-r--r-- 2 tg freewrt 78140 Aug 17 11:04 mircpio_20110817-0wtf2_amd64.deb -rw-r--r-- 3 tg freewrt 72262 Aug 17 11:00 mircpio_20110817-0wtf2_i386.deb -rw-r--r-- 1 tg freewrt 67446 Aug 17 18:21 mircpio_20110817-0wtf2_m68k.deb
Should I upload this to Debian proper? As for the licence: 3-clause UCB (and 2-clause BSD, which is a subset of it), so no problem. I m asking because the other package which I had been using for a long time and not uploaded, jupp, got uploaded recently (during DebConf) on user input (people wondered why it did not yet exist in Debian proper). I guess the old saying if it s not in Debian, it doesn t exist holds true in many parts of the OSS world. It s up to date wrt. standards btw, and lintian-clean save for two pedantic-class warnings (no upstream changelog file, no homepage link) which aren t fulfillable (could link this wlog entry as homepage). If you know Alioth you re familiar with the software formerly known as SourceForge, formerly known as GForge, currently known as FusionForge. My employer both uses it and contributes to it, we run an adapted (mostly themed, prototyping new functions that often end up in FusionForge itself, and backporting functions from FF to our production codebase ) version.
I ve backported the extratabs plugin to appease project managers and other non-technical people while we move our codebase to FF 5.1, and I did so on an installed version of the plugin rather than the source because the latter was tightly integrated with rather heavy packaging style changes.
[ ] dh_builddeb # create fusionforge-plugin-extratabs binary package toplev=$$(pwd); cd plugins/fusionforge-plugin-extratabs; \ p=$$(print -r -- $$(sed -n '/^Package: /s///p' C/control head -1)); \ v=$$(print -r -- $$(sed -n '/^Version: /s///p' C/control head -1)); \ a=$$(print -r -- $$(sed -n '/^Architecture: /s///p' C/control head -1)); \ d=$$ p _$$ v _$$ a .deb; \ rm -f $$toplev/../$$d control.tar.gz data.tar.gz; \ (cd control; find . fgrep -v /.svn sort \ mircpio -oC512 -Hustar -M0x0B -Mgslash) gzip -n9 >control.tar.gz; \ (cd data; find . fgrep -v /.svn sort \ mircpio -oC512 -Hustar -M0x0B -Mgslash) gzip -n9 >data.tar.gz; \ mirtar -M dist -Acf $$toplev/../$$d debian-binary cont*gz dat*gz; \ rm -f control.tar.gz data.tar.gz; \ cd $$toplev; dpkg-distaddfile $$d non-free/devel optional
The hardest part of extending debian/rules with that was to get the autobuild and dpkg-distaddfile call right. This works, even though I d call it a temporary kludge. (No need to tell me I should have used && I know. And I only shell out to mksh(1) because the inner part was already there from before, when I still used ar(1). This was slightly edited for the wlog.) In the meanwhile, apt-extracttemplates can deal with SYSV style filenames in DEB files on Debian sid, but not on Kubuntu hardy, which some people are using as Desktop OS still
Just setup a delay rule following these steps.
1. Go to Tools....Rules Wizard
2. Click 'New' Rule
3. Select "Check messages after sending"
4. Click Next on "Which conditions you want to Check?" dialog.
5. Press yes to "This Rule will be applied to every message" message box
6. In the "What do you want to do with message?" dialog, Select "Defer delivery by a number of minutes"
7. Select your favourite number of minutes.... I usually select 2 mins.
8. Select Finish. and close the Rules Wizard.
Now everytime you send an email it will sit in your outbox
for specified number of minutes. If you ever wanted to change it, delete it etc, You have sufficient time to do it :)
lspci -nn
tells:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) 00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07) 00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03) 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03) 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03) 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03) 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03) 00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 [8086:2944] (rev 03) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93) 00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03) 00:1f.2 SATA controller [0106]: Intel Corporation ICH9M/M-E SATA AHCI Controller [8086:2929] (rev 03) 01:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232] 05:0b.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ba) 05:0b.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04) 05:0b.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 21) 05:0b.3 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev ff) 05:0b.4 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 11) 05:0b.5 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev 11)Things that worked out-of-the-box: Display/Graphics (Intel GMA 4500M HD) The integrated graphics chipset, an Intel GMA 4500M HD, works with the xserver-xorg-video-intel package and the default X.org configuration. No custom /etc/X11/xorg.conf is necessary. The (IMHO non-reflecting?) display runs at 1280 800 at 60 Hz. Cable network device The integrated Intel 82567LM Gigabit Network device works with the
e1000e
kernel module. No customization was necessary.
Touchpad/Trackpoint
The notebook comes with the so called Toshiba Dual Pointing Device a touchpad (+2 buttons) and a trackpoint (+2 buttons). Both worked without customization.
Energy savings/Suspend/Resume
apmd and acpid handle this. No problems yet. Suspend/Resume works. I did not yet test (and I m not sure if I should) hibernate and uswsusp.
Webcam
The webcam is a CNA7157 model or at least detected as such. The video4linux
modules handle it and the cheese application produces pictures.
Volume-control wheel
It works. Module and package information will follow as soon as I figure them out.
Things that needed customization
WLAN (Intel WiFi Link 5100)
The notebook comes with an Intel WiFi Link 5100 device. It does not work out-of-the-box. Following this article, I ve installed the firmware-iwlwifi package and loaded the iwlagn module.
Sound (Intel)
For the sound device to work the snd_hda_intel
module is necessary. Further the following lines must be added to /etc/modprobe.d/alsa-base.conf
# not sure about the first line, start adding the second only options snd-cmipci mpu_port=0x330 fm_port=0x388 options snd-hda-intel index=0 model=toshiba position_fix=1Unsure/Not yet working Temperature sensor After installing the sensors-applet I got two identical temperature displays. I m not sure what they show. Anybody an idea how to examine this? Modem The notebook comes with an internal modem device:
00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07)From what I read I need hsfmodem or the sl-modem packages. Unfortunately the latest version is not available for amd64 from the archive, although it seems to have been built. Untested I did not yet test
lspci -k -nn
tells about the used kernel modules:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: agpgart-intel 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) Subsystem: Toshiba America Info Systems Device [1179:0004] 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem: Toshiba America Info Systems Device [1179:0004] 00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07) Subsystem: Toshiba America Info Systems Device [1179:0001] 00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: e1000e 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: ehci_hcd 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: HDA Intel 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03) Kernel driver in use: pcieport-driver 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03) Kernel driver in use: pcieport-driver 00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 [8086:2944] (rev 03) Kernel driver in use: pcieport-driver 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: uhci_hcd 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: ehci_hcd 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93) 00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] 00:1f.2 SATA controller [0106]: Intel Corporation ICH9M/M-E SATA AHCI Controller [8086:2929] (rev 03) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: ahci 01:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232] Subsystem: Intel Corporation Device [8086:1201] Kernel driver in use: iwlagn 05:0b.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ba) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: yenta_cardbus 05:0b.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: firewire_ohci 05:0b.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 21) Subsystem: Toshiba America Info Systems Device [1179:0001] Kernel driver in use: sdhci-pci 05:0b.3 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev ff) Kernel driver in use: ricoh-mmc 05:0b.4 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 11) Subsystem: Toshiba America Info Systems Device [1179:0001] 05:0b.5 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev 11) Subsystem: Toshiba America Info Systems Device [1179:0001]
vimspell
plugin. Version 1.100 /
released 14-Sep-2005 causes this in conjunction with the Debian vim-gnome
package, version 2:7.2.245-2 (and perhaps others). The solution for me is to
just remove the vimspell
plugin: the upstream author recommends that users
of VIM versions 7 and upwards use the built-in spell checker instead anyway.
Client revenue declined 8% as a result of PC market weakness and a continued shift to lower priced netbooks.Sounds like Microsoft unwillingness to sell XP instead of Vista has a very big effect on it. The adaptaion to the new situation might come after the release on Windows 7. Let s just wait and see Also read Ballmer: Linux Bigger Competitor than Apple, and the follow ups made about the slide presented there. Posted in Proprietary software
CRS: Humane Treatment of Farm Animals: Overview and Issues, December 10, 2008I look forward to hearing/learning more about how they are used (I can t imagine that each report is read by many) and why exactly they were hidden away as they don t seem to be the type of information that should be kept classified.
CRS: FDA s Authority to Ensure That Drugs Prescribed to Children Are Safe and Effective, December 2, 2008
CRS: African American Members of the United States Congress: 1870-2008, December 4, 2008
CRS: The Pigford Case: USDA Settlement of a Discrimination Suit by Black Farmers, January 13, 2009
CRS: Selected Legal and Policy Issues Related to Coalbed Methane Development, March 9, 2004
Next.